The present invention relates to an execution control system applied to software components and employed in the development of software for a computer system handling real-time information, the execution control system including: a method of combining software components which method is adapted to processing requirements and allows software pieces created in accordance with a predetermined standard to be combined; message exchanging between software components; and an operation mode control method for switching operation modes when the software components are executed in a redundant system.
Recently, there has been a demand that the following processes be simplified when a plurality of individually developed software components are combined for a realtime-process: the setting of a condition for combining individual software units; and a process for software update process.
In every software component, whether it is called within a process or from a library, a process is started when a request for a process is generated, and the process is terminated when the requested function is realized. A description will be given below of a conventional method of exchanging messages between software components in response to a request for a process.
FIG. 1 shows a first example of conventional technology. Referring to FIG. l, an apparatus 11 accommodates two processes 1 and 2, wherein the process 1 includes a software component a and a software component b, and the process 2 includes a software component c. An apparatus 13 accommodates one process 3 which includes a software component d. The software component refers to an application program which performs an arbitrary process.
When a plurality of software components are combined in the conventional system, information relating to the combination such as the method of combining, the target software component to be combined and the like is created within the software (program).
As shown in FIG. 1, the software component a contains a logic for transferring an external message to the software component b. The software component b contains a logic whereby the message received from the software component a is transferred to the software component c of the process 2. Instead of being passed from the software component b to the software component c, the message may be passed via a logic for activating the process 2 or via a table/file. The writing of the information from the software component c of the process 2 to the software component d of the process 1 of the apparatus 13 is effected via a socket. The software component d contains a logic for reading the information from the software component c. Instead of being written via the socket, the information may be written from the apparatus 11 to the apparatus 13 by specifying a pertinent interface.
As shown in FIG. 1, the software components a, b, c and d contain combination information (execution request information) for requesting the execution of the software component, the combination information being the information relating to "message reception", "message transmission", "message writing" and "message reading".
FIGS. 2A and 2B show a second example of the conventional technology. Specifically, the second example is disclosed in the Japanese Laid-Open Patent Publication No. 3-191429 whereby messages are collected by a message management part 14, and a message is sent after a virtual destination is converted into a real destination by using a destination correspondence table 15.
In the second example, the message management part 14 converts only the destinations by referring to the destination correspondence table 15. The interface for the message is written in a static manner within the program of the software component (PKG). For example, synchronous control such as message queuing is executed within the program of the software component.
Referring to FIG. 2A, a software component PKG-B sends two messages, i.e. a message a and a message b, to a software component PKG-A. The message comprises: destination information which specifies the message management 14 as the destination; a virtual destination; an interface; and a content of the message.
It is assumed that the message a sent by the software component PKG-B has a virtual destination "001". Accordingly, the message management part 14 refers to the destination correspondence table 15 on the basis of the virtual destination (001) of the message a. It is found as a result of the reference that PKG-A is the destination. As in the case of the message a, the message management part 14 refers to the destination correspondence table 15 on the basis of the virtual destination (001) of the message b. After it is found that PKG-A is the destination of the message, the content of the message b is sent to the software component PKG-A.
When the message b, which is one of the messages sent by the software component PKG-B, has its destination changed to the software component PKG-C, the program of PKG-B is modified so that the virtual destination for referring to the destination correspondence table 15 is changed from "001" to "003", as shown in FIG. 2B.
FIGS. 3A and 3B also show another aspect of the second example of the conventional technology. In this case, the destination is changed by modifying the program. When the message sent from the software component PKG-B to the PKG-A has its destination changed to the software component PKG-C, the content of the software component PKG-B to be sent is modified by modifying the program of the software component PKG-B so that the information that the software component PKG-C is capable of receiving is sent.
FIG. 3A shows a case where the interface is modified and the virtual destination is changed to "001" before sending the message so that the software component PKG-A can receive the message from the software component PKG-B. FIG. 3B shows a case where the destination of the message sent from the software component PKG-B is changed to the software component PKG-C such that the interface of the message is rewritten so as to correspond to the new destination, that is, so that the software component PKG-C can receive the message.
A description will now be given of management of the operation mode of the redundancy system in the conventional system. Conventionally, the operation mode is managed by an application. Specifically, when the operation is switched from one mode to another, the process is carried out in the new mode. The operation mode management is performed such that, if the active operation mode is effective in the application, the acquired data is evaluated and the result is output, and if the test mode is effective, the acquired data is discarded and the test data is evaluated. In this way, the operation mode is always monitored so that the manner in which the process is executed is selected to be compatible with the effective operation mode.
FIG. 4 is a diagram explaining the operation mode management system in the conventional system.
The operation mode in the redundancy system is determined such that, when a request for switching modes is input to the application software (S1), the application software refers to the operation mode of the system to which it belongs. First, the application software determines whether or not the system to which it belongs to is being operated in the test operation mode (S2). If it is determined that the system is being operated in the test operation mode, the data acquired during the execution of the application software is discarded so that the test data is evaluated (S3). If it is determined that the system is being operated in the active operation mode by referring to the mode of the system (S4), the data acquired during the execution of the application software is evaluated and output (S5). If it is determined that the system is being operated neither in the test operation mode nor in the active operation mode, the process is executed according to a mode other than these two modes, or an determination of error is made (S6).
However, the conventional methods described above have the following problems.
As for the first example of the conventional technology, information relating to the combination such as the method of combining software components and the target software component to be combined is set in the program. Therefore, a modification of a program is necessary when the apparatus/process configuration or the combination of software components is to be changed. Another problem of the first example of the conventional technology is that, if the method of combining software components is such that it allows for all the possible combinations, that is, if the socket is made compatible to all the possible combinations, a large degree of degradation in the performance results because of an increase in the OS overhead. Still another problem is that, since the information relating to the combination is set in the program, a complex software structure results so that it is difficult for an outsider to modify the program.
The second example of the conventional technology has a problem in that, since the program should be modified when the destination of the message is to be changed, independence of software components suffers.
Another problem of the second example of the conventional technology is that, in a software component in which messages are held in a queue, the program is to be modified when the number of messages held in a queue, the process to be executed when a message that should not be held in a queue has arrived, or the time that should be allowed for before a message arrives is to be modified.
In the second example of the conventional technology, the interface distribution should be modified when the message originator or the content of the sent message is modified. This modification of the interface means a modification of the program. Hence, independence of the software components suffers.
The second example of the conventional technology also has a problem in that it is impossible to detect an incident in which an activation message is sent to a plurality of software components, because the management of a plurality of messages is performed within the software component. Still another problem is that, if a modification occurs in one portion of a stream of successive messages, the program of all the related software components should be modified, thus decreasing the degree of independence of the software components.
Still another problem of the second example of the conventional technology is that the mere modification of the destination listed in the destination correspondence table does not serve the purpose, and the interface should also be modified so as to be compatible with the new destination, because different software components have different interfaces.
Further, the operation mode management system in the conventional redundancy system is such that the switching of the operation modes is managed by the application software. Hence, it is necessary to reform the application software whenever the application is used in a different system or whenever a new operation mode is added.